LambdaをサポートしたCodeBuildでAWS CLIを実行してみた

昨年、2023年11月のアップデートで、コンピュートリソースとして AWS Lambda をサポートしたAWS CodeBuild。AWSCLI(v2)の実行環境として使えることを試す機会がありましたので、紹介させていただきます。

CodeBuild プロジェクトの作成

AWS マネージドコンソールを利用して、CodeBuild プロジェクトを作成しました。

環境

コンピューティングリソースとして「Lambda」を指定しました。

• OS: Amazon Linux
• ランタイム: Node
• イメージ: aws/codebuild/amazonlinux-aarch64-lambda-standard:nodejs20

Buildspec

ビルドコマンドとして、 aws --version を指定しました。

• buildspec.yaml

version: 0.2

phases:
  build:
    commands:
       - aws --version

動作確認

作成したプロジェクトで「ビルドを開始」

ビルドログの出力で、AWSCLIのバージョンを確認することができました。

• aws --version 実行結果

[Container] 2024/05/23 **:**:**.** Running command aws --version
aws-cli/2.14.4 Python/3.11.6 Linux/5.10.215-223.850.amzn2.aarch64 exec-env/AWS_Lambda_Image exe/aarch64.amzn.2023 prompt/off

DynamoDB操作

AWSリソースの操作に利用できる事を確認しました。

サービスロール設定

CodeBuildプロジェクトのサービスロールに、許可ポリシーとして「AmazonDynamoDBReadOnlyAccess」を付与しました。

ビルドコマンド追加

dynamodb のテーブル一覧を確認 (list-tables )を追加しました。

version: 0.2

phases:
  build:
    commands:
       - aws --version
       - aws dynamodb list-tables 

ビルド結果

aws dynamodb list-tables の実行結果を確認できました。

[Container] 2024/05/23 **:**:** Running command aws dynamodb list-tables
{
    "TableNames": [
        "table_default"
    ]
}

フェーズ詳細で確認した実行時間、10秒前後でした。

まとめ

Lambdaを実行環境とした AWS CodeBuild、少ない待ち時間での利用が期待できます。

CodeBuildのサービスロールを 適切な最小権限を付与して利用する事で意図せぬリソース操作の回避や、実行履歴を残せる点なども利点になります。

S3バケット間のファイル同期を、aws s3 sync を定期的に実現する必要がある場合、同期対象が小規模な間は CodeBuild の 実行環境として Lambdaを利用。

もし将来的に実行時間が 15分を超過する規模となり、Lambdaの手にあまる状況となった場合には、CodeBuild の実行環境を Lambdaから EC2に切り替える利用をお試しください。